Add Proxy mode for FlowAggregator #6920
Conversation
| @@ -100,7 +100,7 @@ func makeDefaultElementsWithValue(infoElements []*entities.InfoElement) ([]entit | |||
| return elementsWithValue, nil | |||
| } | |||
|
|
|||
| func newPreprocessor(infoElementsV4, infoElementsV6 []*entities.InfoElement, inCh <-chan *entities.Message, outCh chan<- entities.Record) (*preprocessor, error) { | |||
| func newPreprocessor(infoElementsV4, infoElementsV6 []*entities.InfoElement, inCh <-chan *entities.Message, outCh chan<- *entities.Message) (*preprocessor, error) { | |||
There was a problem hiding this comment.
@tnqn I had to revert from a Record output channel back to a Message output channel. I wanted the ability to preserve message header information (observation domain id, exporter address) so that the information can be added to proxied records using the standard originalX information elements (e.g. originalObservationDomainId).
antoninbas
force-pushed
the
fa-add-proxy-mode
branch
2 times, most recently
from
4722a39 to
79d8f6d
Compare
In Proxy mode, connection data is not buffered in the FlowAggregator and records from source and destination Nodes are not correlated. Instead, records are proxied directly to the destination collector. In Proxy mode, only the IPFIX exporter is supported. A simple e2e test is added to test this new mode. Fixes antrea-io#6773 Signed-off-by: Antonin Bas <[email protected]>
antoninbas
force-pushed
the
fa-add-proxy-mode
branch
2 times, most recently
from
9d17e74 to
6f4d437
Compare
Signed-off-by: Antonin Bas <[email protected]>
antoninbas
force-pushed
the
fa-add-proxy-mode
branch
from
6f4d437 to
c33ead7
Compare
| cpInput.NumExtraElements += len(infoelements.AntreaSourceStatsElementList) + len(infoelements.AntreaDestinationStatsElementList) + | ||
| len(infoelements.AntreaFlowEndSecondsElementList) + len(infoelements.AntreaThroughputElementList) + len(infoelements.AntreaSourceThroughputElementList) + len(infoelements.AntreaDestinationThroughputElementList) | ||
| } else { | ||
| // originalObservationDomainId, originalExporterIPv4Address, originalExporterIPv6Address |
There was a problem hiding this comment.
I noticed that there was an issue and commit for removing these extra elements before: #2361, I am wondering will the old issue still valid? or those were added by aggregator and won't happen on proxy mode?
According to the issue, originalExporterIPv4Address/originalExporterIPv6Address are Node antrea-gateway IPs? How could user to know Node IPs and gateway IPs mapping? or it's user's responsibility and no way to do such correlation from Antrea aggregator?
There was a problem hiding this comment.
I suppose there will be a document update for these new elements and proxy mode in the following PR?
There was a problem hiding this comment.
These fields don't make sense in aggregation mode because we are "merging" 2 records. The issue mentions this:
One option is to remove this as the original exporter IP does not make sense when correlating the flow records. The second option is to add the exporter IP in the flow record sent by the Flow Exporter and have two different fields corresponding to each exporter (source and destination).
This was the true problem IMO, not the fact that we use the gateway IP. Having these fields be a "private" overlay IP is fine IMO, as long as it is unique for a given cluster.
In proxy mode, there is no aggregation, so the fields "make sense".
Now these fields may not be the most useful to have, and they do add a few bytes to each record. But I would say it's pretty standard to have them and they can be used as a unique identifier for the "source" exporter.
I suppose there will be a document update for these new elements and proxy mode in the following PR?
Yes I will be able to add new fields to the documentation before we release Antrea v2.3.
| fa.fillK8sMetadata(sourceAddress, destinationAddress, record, startTime) | ||
| } | ||
| fa.fillPodLabels(sourceAddress, destinationAddress, record, startTime) | ||
| if err := fa.fillClusterID(record); err != nil { |
There was a problem hiding this comment.
Should this be the same for all records in one cluster?
There was a problem hiding this comment.
Yes, but sending "common" data separately to avoid the duplication and reduce the size of records requires using IPFIX option templates. We don't have support for them in go-ipfix yet. It's on my roadmap (I can open an issue for it), but is not high priority IMO.
| @@ -100,7 +100,7 @@ func makeDefaultElementsWithValue(infoElements []*entities.InfoElement) ([]entit | |||
| return elementsWithValue, nil | |||
| } | |||
|
|
|||
| func newPreprocessor(infoElementsV4, infoElementsV6 []*entities.InfoElement, inCh <-chan *entities.Message, outCh chan<- entities.Record) (*preprocessor, error) { | |||
| func newPreprocessor(infoElementsV4, infoElementsV6 []*entities.InfoElement, inCh <-chan *entities.Message, outCh chan<- *entities.Message) (*preprocessor, error) { | |||
|
/test-all |
antoninbas
added
the
action/release-note
In Proxy mode, connection data is not buffered in the FlowAggregator and records from source and destination Nodes are not correlated. Instead, records are proxied directly to the destination collector. In Proxy mode, only the IPFIX exporter is supported.
A simple e2e test is added to test this new mode.
Fixes #6773